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Abstract —We present an automated compositional program 
verification technique for safety properties based on conditional 
inductive invariants. For a given program part (e.g., a single 
loop) and a postcondition <p, we show how to, using a Max-SMT 
solver, an inductive invariant together with a precondition can be 
synthesized so that the precondition ensures the validity of the 
invariant and that the invariant implies <p. From this, we build 
a bottom-up program verification framework that propagates 
preconditions of small program parts as postconditions for 
preceding program parts. The method recovers from failures 
to prove the validity of a precondition, using the obtained 
intermediate results to restrict the search space for further proof 
attempts. 

As only small program parts need to be handled at a time, 
our method is scalable and distributable. The derived conditions 
can be viewed as implicit contracts between different parts of 
the program, and thus enable an incremental program analysis. 

I. Introduction 

To have impact on everyday software development, a ver¬ 
ification engine needs to be able to process the millions of 
lines of code often encountered in mature software projects. 
At the same time, the analysis should be repeated every 
time developers commit a change, and should report feed¬ 
back in the course of minutes, so that fixes can be applied 
promptly. Consequently, a central theme in recent research 
on automated program verification has been scalability. As 
a natural solution to this problem, compositional program 
analyses ffl-E) have been proposed. They analyze program 
parts (semi-)independently and then combine the results to 
obtain a whole-program proof. 

For this, a compositional analysis has to predict likely 
intermediate assertions that allow us to break whole-program 
reasoning into many instances of local reasoning. This strat¬ 
egy simplifies the individual reasoning steps and allows dis¬ 
tributing the analysis 0. The disadvantage of compositional 
analyses has traditionally been their precision: local analyses 
must blindly choose the intermediate assertions. While in some 
domains (e.g. heap) some heuristics have been found J2], effec¬ 
tive strategies for guessing and/or refining useful intermediate 
assertions or summaries in arithmetic domains remains an 
open problem. 

In this paper we introduce a new method for predicting and 
refining intermediate arithmetic assertions for compositional 
reasoning about sequential programs. A key component in 
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our approach is Max-SMT solving. Max-SMT solvers can 
deal with hard and soft constraints, where hard constraints are 
mandatory, and soft constraints are those that we would like to 
hold, but are not required to. Hard constraints express what is 
needed for the soundness of our analysis, while soft ones favor 
the solutions that are more useful for our technique. More 
precisely, we use Max-SMT to iteratively infer conditional 
inductive invariant which prove the validity of a property, 
given that a precondition holds. Hence, if the precondition 
holds, the program is proved safe. Otherwise, thanks to a 
novel program transformation technique we call narrowing 
we exploit the failing conditional invariants to focus on what 
is missing in the safety proof of the program. Then new 
conditional invariants are sought, and the process is repeated 
until the safety proof is finally completed. Based on this, we 
introduce a new bottom-up program analysis procedure that 
infers conditional invariants in a goal-directed manner, starting 
from a property that we wish to prove for the program. Our 
approach makes distributing analysis tasks as simple as in 
other bottom-up analyses, but also enjoys the precision of 
CEGAR-based provers. 


II. Illustration of the Method 


In this section, we illustrate the core concepts of our 
approach by using some small examples. We will give the 
formal definition of the used methods in Sect. El 

We handle programs by considering one strongly connected 
component (SCC) C of the control-flow graph at a time, 
together with the sequential parts of the program leading to C, 
either from initial states or other SCCs. 

Instead of program invariants, for each SCC we synthesize 
conditional inductive invariants. These are inductive properties 
such that they may not always hold whenever the SCC is 
reached, but once they hold, then they are always satisfied. 

a) Conditional Inductive Invariants: 

As an example, consider the program snip¬ 
pet in Fig. Q] where we do not assume any 
knowledge about the rest of the program. 

To prove the assertion, we need an induc¬ 
tive property Q for the loop such that 
Q together with the negation of the loop 


while i > 0 do 

x := x + 5; 
i := i - 1; 

done 

assertfx > 0); 
Fig. l. 


This concept was previously introduced with the name “quasi-invariant” 
in 0 in the different context of proving program non-termination. 

2 This narrowing is inspired by the narrowing in term rewrite systems, and 
is unrelated to the notion with the same name used in abstract interpretation. 


condition i > 0 implies the assertion. Using our constraint¬ 
solving based method CondSafe (cf. Sect. IIV-Ab . we find 
Qi = x + 5 • i > 0. The property Qi can be seen as a 
precondition at the loop entry for the validity of the assertion. 


b) Combining Conditional Inductive Invariants: Once 
we have found a conditional inductive invariant for an SCC, 
we use the generated preconditions as postconditions for its 
preceding SCCs in the program. 


while j > 0 do 

j := j - 1 ; 
i:=i + l; 

done 

Fig. 2. 


As an example, assume that the loop 
from Fig. [I] is directly preceded by the 
loop in Fig. [2] We now use the pre¬ 
condition Qi we obtained earlier as in¬ 
put to our conditional invariant synthesis 
method, similarly to the assertion in Fig. [T] 
Thus, we now look for an inductive property Q 2 that, together 
with -i(j > 0), implies Qi. In this case we obtain the 
conditional invariant Q 2 = j > 0 A x + 5 • (i + j) > 0 for 
the loop. As with Qi, now we can see Q 2 as a precondition 
at the loop entry, and propagate Q 2 up to the preceding SCCs 
in the program. 


c) Recovering from Failures: When we cannot prove 
that a precondition always holds, we try to recover and find 
an alternative precondition. In this process, we make use of 
the results obtained so far, and narrow the program using 
our intermediate results. As an example, consider the loop 
in Fig. [2 

We again apply our method 
CondSafe to find a conditional in¬ 
variant for this loop which, together 
with the loop condition, implies the 
assertion in the loop body. As it 
can only synthesize conjunctions of 
linear inequalities, it produces the 
conditional invariant Q 3 = x > y for the loop. However, 
assume that the precondition Q 3 could not be proven to always 
hold in the context of our example. In that case, we use 
the obtained information to narrow the program and look for 
another precondition. 

Intuitively, our program narrow¬ 
ing reflects that states represented 
by the conditional invariant found 
earlier are already proven to be safe. 

Hence, we only need to consider 
states for which the negation of the 
conditional invariant holds, i.e., we 
can add its negation as an assump¬ 
tion to the program. In our example, this yields the modified 
version of Fig.[3]displayed in Fig. [4] Another call to CondSafe 
then yields the conditional invariant Q' 3 = x < y for the 
loop. This means that we can ensure the validity of the 
assertion if before the conditional statement we satisfy that 
-i(x > y) => x < y, or equivalently, x y. In general, this 
narrowing allows us to find (some) disjunctive invariants. 




if -i(x>y) then 
while -i(x>y) do 
assert(x fz y); 
x :=x+ 1 ; 
y :=y + l; 
done 


Fig. 4. 


while unknoum() do 

assert(x f y); 
x := x+ 1 ; 

y :=y + i; 

done 

Fig. 3. 


III. Preliminaries 

1) SAT, Max-SAT, and Max-SMT: Let V he a fixed set of 
propositional variables. For p £ V, p and -1 p are literals. A 
clause is a disjunction of literals iiV- • -Vl n . A (CNF) proposi¬ 
tional formula is a conjunction of clauses C\ A • ■ • A C m . The 
problem of propositional satisfiability (SAT) is to determine 
whether a propositional formula is satisfiable. An extension 
of SAT is satisfiability modulo theories (SMT) 0, where 
satisfiability of a formula with literals from a given background 
theory is checked. We will use the theory of quantifier-free 
integer (non-)linear arithmetic, where literals are inequalities 
of linear (resp. polynomial) arithmetic expressions. 

Another extension of SAT is Max-SAT 0. which general¬ 
izes SAT to finding an assignment such that the number of 
satisfied clauses in a given formula F is maximized. Finally, 
Max-SMT combines Max-SAT and SMT. A (weighted partial) 
Max-SMT problem is a formula of the form H 1 A ... A //„ A 
[5i,wi] A ... A [S m ,w m ], where the hard clauses Hi and the 
soft clauses Sj (with weight ujj) are disjunctions of literals 
over a background theory, and the aim is to find a model of 
the hard clauses that maximizes the sum of the weights of the 
satisfied soft clauses. 

2) Programs and States: We make heavy use of the 

program structure and hence represent programs as graphs. 
For this, we fix a set of (integer) program variables V = 
{ui,... ,v n } and denote by -F(V) the formulas consisting of 
conjunctions of linear inequalities over the variables V. Let C 
be the set of program locations, which contains a canonical 
start location £q. Program transitions T are tuples (£,t,£'), 
where £ and f £ £ represent the pre- and post-location re¬ 
spectively, and t £ JF(y LJ V') describes its transition relation. 
Here V' = ..., are the post-variables, i.e., the values 

of the variables after the transition^ A transition is initial if 
its source location is £q. A program is a set of transitions. We 
view a program V = (£, T) as a directed graph (the control- 
flow graph, CFG), in which edges are the transitions T and 
nodes are the locations £0 

A state s = (£, v) consists of a location £ £ £ and a 
valuation v : V — > Z. A state (£,v) is initial if £ = £q. 
We denote an evaluation step with transition t = (£, r, £') 
by (£,v) —> t {£', 1 /), where the valuations v, v' satisfy the 
formula r of t. We use -y-p if we do not care about the 
executed transition, and — yf, to denote the transitive-reflexive 
closure of — y-p. We say that a state s is reachable if there 
exists an initial state So such that So —>■£> s. 

3) Safety and Invariants: An assertion ( t , p) is a pair of a 
transition t £ T and a formula ip £ F(V). A program V is 
safe for the assertion (t, tp) if for every evaluation (£ 0 , t>o) — yf> 
o —y t (£,v), we have that v \= ip holds0 Note that proving 
that a formula tp always holds at a location £ can be handled 

3 For tp £ J-(V), tp' £ J-(V') is the version of tp using primed variables. 

4 Since we label transitions only with conjunctions of linear inequalities, 
disjunctive conditions are represented using several transitions with the same 
pre- and post-location. Thus, P is actually a multigraph. 

5 Here, —yf o —rt denotes arbitrary program evaluations that end with an 
evaluation step using t. 




in this setting by adding an extra location £* and an extra 
transition t* = (£, true, £*) and checking safety for ( t*,ip). 

We call a map I : C —> _F(V) a program invariant (or 
often just invariant ) if for all reachable states [t , v), we have 
v (= I{£) holds. An important class of program invariants 
are inductive invariants. An invariant I is inductive if the 
following conditions hold: 

Initiation: T J= Z(4) 

Consecution: For (£, r, £') £ V: T{£) At |= If) 1 

4) Constraint Solving for Verification: Inductive invariants 
can be generated using a constraint-based approach 0, |8l . 
The idea is to consider templates for candidate invariant 
properties, such as (conjunctions of) linear inequalities. These 
templates contain both the program variables V as well as 
template variables Vt, whose values have to be determined 
to ensure the required properties. To this end, the conditions 
on inductive invariants are expressed by means of constraints 

of the form 3 Vt -V V.Any solution to these constraints 

then yields an invariant. In the case of linear arithmetic, Farkas’ 
Lemma 0 is often used to handle the quantifier alternation in 
the generated constraints. Intuitively, it allows one to transform 
3V problems encountered in invariant synthesis into 3 prob¬ 
lems. In the general case, an SMT problem over non-linear 
arithmetic is obtained, for which effective SMT solvers exist 
OH, ED. By assigning weights to the different conditions, 
invariant generation can be cast as an optimization problem in 
the Max-SMT framework 0 , lfl2l . 

IV. Proving Safety 

Most automated techniques for proving program safety 
iteratively construct inductive program invariants as over¬ 
approximations of the reachable state space. Starting from 
the known set of initial states, a process to discover more 
reachable states and refine the approximation is iterated, until 
it finally reaches a fixed point (i.e., the invariant is inductive) 
and is strong enough to imply program safety. However, this 
requires taking the whole program into account, which is 
sometimes infeasible or undesirable in practice. 

In contrast to this, our method starts with the known unsafe 
states, and iteratively constructs an under-approximation of the 
set of safe states, with the goal of showing that all initial states 
are contained in that set. For this, we introduce the notion of 
conditional safety. Intuitively, when proving that a program is 
(t. ip)-conditionally safe for the assertion (t,<p) we consider 
evaluations starting after a — (£, v) step, where v satisfies (p, 
instead of evaluations starting at an initial state. In particular, 
a program that is (to, T)-conditionally safe for (f, ip) for all 
initial transitions to is (unconditionally) safe for (t,<p). 

Definition 1 (Conditional safety). Let V be a program, t, t 
transitions and <p,(p £ .F(V). The program V is (t,ip)- 
conditionally safe for the assertion (t, ip) if for any evaluation 
that contains —(£, v) —y’f, (£, v ) —y t {£, v), we have v \= (p 
implies that v \= ip. In that case we say that the assertion 
(■ t,<p ) is a precondition for the postcondition (t,ip). 


Conditional safety is “transitive” in the sense that if a set 
of transitions £ = {4...., t rn } dominates /Q and for all i = 
1,..., to we have V is (£j, ipf )-conditionally safe for (f, <p) and 
V is safe for (ti,ipi), then V is also safe for (t,(p). In what 
follows we exploit this observation to prove program safety 
by means of conditional safety. 

A program component C of a program V is an SCC of 
the control-flow graph, and its entry transitions (or entries) 
£c are those transitions t = (£, r, £') such that t 0 C but 
£' appears in C. By considering each component as a single 
node, we can obtain from V a DAG of SCCs, whose edges 
are the entry transitions. Our technique analyzes components 
independently, and communicates the results of these analyses 
to other components along entry transitions. 

Given a component C and an assertion (t, ip) such that 
t qL C but the source node of t appears in C, we call t an 
exit transition of C. For such exit transitions, we compute a 
sufficient condition fit for each entry transition t £ £c such 
that C U {£} is (f, ^^-conditionally safe for (t, <p). Then we 
continue reasoning backwards following the DAG and try to 
prove that V is safe for each (f, tbfi. If we succeed, following 
the argument above we will have proved V safe for (f, ip). 

In the following, we first discuss how to prove conditional 
safety of single program components in Sect. IIV-AI and then 
present the algorithm that combines these local analyses to 
construct a global safety proof in Sect. IIV-BI 

A. Synthesizing Local Conditions 

Here we restrict ourselves to a program component C and 
its entry transitions £c , and assume we are given an assertion 
(i ex it, V 5 ), where t exit = (4xit,_T ex i t , 4xit) is an exit transition 
of C (i.e., f ex it ^ C and 4xit appears in C). We show 
how a precondition for (t ex it, V 5 ) can be obtained for 

each t £ £c- Here we only consider the case of ip being a 
single clause (i.e., a disjunction of literals); if ip is in CNF, 
each conjunct is handled separately. The preconditions on the 
entry transitions will be determined by a conditional inductive 
invariant , which like a standard invariant is inductive, but not 
necessarily initiated in all program runs. Indeed, this initiation 
condition is what we will extract as precondition and propagate 
backwards to preceding program components in the DAG. 

Definition 2 (Conditional Inductive Invariant). We say a map 
Q : C —» -F(V) is a conditional (inductive) invariant for a 
program (component) V if for all (£,v) —>-p {£! ,v r ), we have 
v |= Q(£) implies v' J= Q(£'). 

Conditional invariants are convenient tools to express con¬ 
ditions for safety proving, allowing reasoning in the style of 
“if the condition for Q holds, then the assertion (t, ip) holds”. 

Example 1. Consider the program snippet in Fig. [5] A con¬ 
ditional inductive invariant supporting safety of this program 
part is Qs(4) = x + 5 ■ i > 50, Qs(4) = x > 50. In fact, any 
conditional invariant Q m { 4) = x+m-i > 50 with 0 < m < 5 

6 We say a set of transitions £ dominates transition t if every path in the 
CFG from £0 that contains t must also contain some t G £■ 








while i > 0 do 

x := x + 5; 

i := i - 1; 

done 

assert(x > 50) 

Fig. 5. Source code of program snippet and its CFG. 

would be a conditional inductive invariant that, together with 
the negation of the loop condition i < 0, implies x > 50. 

We use a Max-SMT-based constraint-solving approach to 
generate conditional inductive invariants. Unlike in f5j. to 
use information about the initialization of variables before a 
program component, we take into account the entry transitions 
£c- The precondition for each entry transition is the conditional 
invariant that has been synthesized at its target location. 

To find conditional invariants, we construct a constraint 
system. For each location £ in C we create a template 
It.k(V) = Ai <j<k h,j,k{V) which is a conjunction of k linear 
inequations^ of the form h:.,j,k. (V) = iij + Y1 V £v • v < 0, 

where the iej v are fresh variables from the set of 
template variables Vt- We then transform the conditions for a 
conditional invariant proving safety for the assertion (iexit)V 3 ) 
to the constraints in Fig. [6] Here, e.g.. If k refers to the variant 
of If j c using primed versions of the program variables V, but 
unprimed template variables Vt- 

In the overall constraint system, we mark the Conse¬ 
cution and Safety constraints as hard requirements. Thus, 
any solution to these constraints is a conditional inductive 
invariant implying our assertion. However, as we mark the 
Initiation constraints as soft, the found conditional invariants 
may depend on preconditions not implied by the direct context 
of the considered component. On the other hand, the Max- 
SMT solver prefers solutions that require fewer preconditions. 
Overall, we create the following Max-SMT formula 

Ffc d =/\C tifc A /\ V-'Pit ijik ) A§ fc A /\ 

t£C t(z£c t££c 

where the p\ t . k are propositional variables which are true 
if the Initiation condition I t ,j,k is satisfied, and ojj; is the 
corresponding weight. H We use F/,. in our procedure CondSafe 
in Algo. [I] 

In CondSafe, we iteratively try “larger” templates of more 
conjuncts of linear inequations until we either give up (in our 
implementation, MAX_CONJUNCTS is 3) or finally find a 
conditional invariant. Note, however, that here we are only 
trying to prove safety for one clause at a time, which reduces 
the number of required conjuncts as compared to dealing with 
a whole CNF in a single step. If the Max-SMT solver is 
able to find a model for F&, then we instantiate our invariant 

7 In our overall algorithm, k is initially 1 and increased in case of failures. 

s Farkas’ Lemma is applied locally to the subformulas C t,k, I t,j,k and Sj., 
and weights are added on the resulting constraints over the template variables. 


Algorithm 1 Proc. CondSafe computing conditional invariant 
Input: component C, entry transitions £q , assertion (Cxit, p) 
s.t. f ex it is an ex it transition of C and ip is a clause 
Output: None | Q, where Q maps locations in C to conjunc¬ 
tions of inequations 
I: k <- 1 
2: repeat 

3: construct formula F*, from C, £c and (f e xit,p) 

4: a «- Max-SMT-solver(F fc ) 

5: if a is a model then 

6: a (Ie,k) | £ in C} return Q 

7: k 4 - k + 1 

8: until k > MAX CONJUNCTS return None 


templates Ifj. with the values found for the template variables 
in the model a, obtaining a conditional invariant Q. When we 
obtain a result, for every entry transition t = (£, r, £') G £c 
the conditional invariant Q(£') is a precondition that implies 
safety for the assertion (i ex it, p)- The following theorem states 
the correctness of this procedure. 

Theorem 1. Let C be a component, £c its entry transitions, 
and (fexit, p) an assertion with f ex it an exit transition ofC and 
ip a clause. If the procedure call CondSafe(C, £c, (fexit, P)) 
returns Q ^ None, then Q is a conditional inductive invariant 
for C and V is (f, Q(£'))-conditionally safe for (f ex it, p) for 
all t = (£, r, £') G £q- 

Proof. All proofs can be found in Appendix [A] □ 

B. Propagating Local Conditions 

In this section, we explain how to use the local procedure 
CondSafe to prove safety of a full program. To this end we now 
consider the full DAG of program components. As outlined 
above, the idea is to start from the assertion provided by 
the user, call the procedure CondSafe to obtain preconditions 
for the entry transitions of the corresponding component, and 
then use these preconditions as assertions for preceding com¬ 
ponents, continuing recursively. If eventually for each initial 
transition the transition relation implies the corresponding 
preconditions, then safety has been proven. If we fail to 
prove safety for certain assertions, we backtrack, trying further 
possible preconditions and conditional invariants. 

The key to the precision of our approach is our treatment 
of failed proof attempts. When the procedure CondSafe finds 
a conditional invariant Q for C, but proving (t, Q(£ / )) as a 
postcondition of the preceding component fails for some t = 
(£, r, £') G £c, we use Q to narrow our program representation 
and filter out evaluations that are already known to be safe. 

As outlined above, in our proof process we treat each 
clause of the conjunction Q(£') separately, and pass each 
one as its own assertion to preceding program components, 
allowing for a fine-grained program-narrowing technique. By 
construction of Q, evaluations that satisfy all literals of Q(£') 
after executing t = (£, r, £') G £c are safe. Thus, among the 
evaluations that use t, we only need to consider those where 








Initiation: For t = (£, T, £') G £c, 1 < j < k: 

Consecution: For i = (A r, £') G C: 

Safety: For fexit - (-^exit, ’i'exit, -^exit) ■ 
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Fig. 6. Constraints used in CondSafe(C, £c , (t ex it , V 3 )) 


Algorithm 2 Procedure CheckSafe for proving a program safe 
for an assertion_ 

Input: Program V, a component C, entries £c, assertion 
(texiti p) s.t. texit is an exit transition of C and ip a clause 

Output: Safe | Maybe 

1: let (^exit) texit) ^exit) — fexit 

2 : if (r ex it => s') then return Safe 
3: else if 4xit = £q then return Maybe 

4: Q<- CondSaf e(C,£ c , (texit, <p)) 

5: if Q = None then return Maybe 

6: for all t = (£,t,£') G Sc, L G Q(£') do 
7: CV component^, V) 

8: <% <- entries(C, T 5 ) 

9: res[t, L] CheckSafe("P, C, (t, L)) 

io: if Vt = ( £,t,£ ') e£ c ,L g Q(A) . res[t,L] = Safe then 
li: return Safe 
12 : else 

13: &<-{(£,rA-.( /\ L'),£') | t = (£,t,£') G £c} 

LeQ{£') 
res [t,L]= Maybe 

14: C f— {(*, r A -'Q(t')'A -.Q(£), £') | (f, r, £') G C} 

15: return CheckSafe(F > , C, £c, (texit, <f)) 


at least one literal in Q{£') does not hold. Hence, we narrow 
each entry transition by conjoining it with the negation of the 
conjunction of all literals for which we could not prove safety 
(see line 13 in Algo. 0. Note that if there is more than one 
literal in this conjunction, then the negation is a disjunction, 
which in our program model implies splitting transitions. 

We can narrow program components similarly. For a tran¬ 
sition t = (£, r, £') G C, we know that if either Q(£) or 
Q(£'Y holds in an evaluation passing through t, the program 
is safe. Thus, we narrow the program by replacing r by 
r A -i Q(£) A -i Q(£'Y (see line 14 in Algo. 0. 

This narrowing allows us to generate disjunctive conditional 
invariants, where each result of CondSafe is one disjunct. Note 
that not all disjunctive invariants can be discovered like this, 
as each intermediate result needs to be inductive using the 
disjuncts found so far. However, this is the pattern observed 
in phase-change algorithms oca. 

Our overall safety proving procedure CheckSafe is shown 
in Algo.0 The helper procedures component and entries are 
used to find the program component for a given location and 
the entry transitions for a component. The result of CheckSafe 
is either Maybe when the proof failed, or Safe if it succeeded. 
In the latter case, we have managed to create a chain of 
conditional invariants that imply that (t e xit,y?) always holds. 


Theorem 2. Let V be a program, C a component and 
£c its entries. Given an assertion (i e xit,y?) such that 
fexit is an exit transition of C and ip is a clause, if 
CheckSafe^, C, £c, (texit, s)) = Safe, then V is safe for 

(texit, yO- 

Example 2 . We demonstrate CheckSafe on the program 
displayed on Fig. 0 called V in the following, which is an 
extended version of the example from Fig. 0 

We want to prove the assertion (f. 5 ,x^y). Flence we make 
a first call CheckSafe^, {f-t}, {£ 3 }, (ts, x ^ y)): the non¬ 
trivial SCC containing £2 is {£4} and its entry transitions 
are {f 3 }. Flence, we call CondSafe({i4}, {£3}, (i 5 , x ^ y)) 
and the resulting conditional invariant for £2 is either x < y 
or y < x. Let us assume it is y < x. In the next step, 
we propagate this to the predecessor SCC {£ 2 }, and call 
CheckSafe(P, {t 2 }, {h}, (i 3 , y < x)). 

In turn, this leads to calling CondSafe({f 2 }, {fi}, (f 3 , y < 
x)) to our synthesis subprocedure. No conditional invariant 
supporting this assertion can be found, and hence None is 
returned by CondSafe, and consequently Maybe is returned 
by CheckSafe. Hence, we return to the original SCC {£ 4 } 
and its entry {i 3 }, and then by narrowing we obtain two new 
transitions: 

£4 = (f 2 ,x' = x+lAy' = y + lA ->(y < x),f 2 ), 

t 3 = (£i,x <0Ax'=xAy'=yA ->(y < x), if). 

Using these, we call CheckSafe^, {£ 4 }, {f 3 }, (£5, x^y)). The 
next call to CondSafe then yields the conditional invariant 
x < y at £ 2 , which is in turn propagated backwards with the 
call CheckSafeCP, {f 2 }, {ti}, (f 3 , x < y)). This then yields a 
conditional invariant x < y at £\, which is finally propagated 
back in the call CheckSafe^, {},{}, (ti, x < y)), which 
directly returns Safe. 

C. Improving Performance 

The basic method CheckSafe 
can be extended in several ways 
to improve performance. We now 
present a number of techniques 
that are useful to reduce the run¬ 
time of the algorithm and dis¬ 
tribute the required work. Note 
that none of these techniques influ¬ 
ences the precision of the overall 
framework. 

a) Using conditional invari¬ 
ants to disable transitions: When 
proving an assertion, it is often 



Fig. 7. 











necessary to find invariants that show the unfeasibility of 
some transition, which allows disabling it. In our framework, 
the required invariants can be conditional as well. Therefore, 
CheckSafe must be called recursively to prove that the con¬ 
ditional invariant is indeed invariant. In our implementation, 
we generate constraints such that every solution provides 
conditional invariants either implying the postcondition or 
disabling some transition. By imposing different weights, we 
make the Max-SMT solver prefer solutions that imply the 
postcondition. 

b) Handling unsuccessful proof attempts: One important 
aspect is that the presented algorithm does not learn facts 
about the reachable state space, and so duplicates work when 
assertions appear several times. To alleviate this for unsuccess¬ 
ful recursive invocations of CheckSafe, we introduce a simple 
memoization technique to avoid repeating such calls. So when 
CheckSafe^, C, Sc, (t, p)) = Maybe, we store this result, 
and use it for all later calls of CheckSafe^, C, Sc, (f <p))- This 
strategy is valid as the return value Maybe indicates that our 
method cannot prove the assertion (t, p) at all, meaning that 
later proof attempts will fail as well. In our implementation, 
this memoization of unsuccessful attempts is local to the 
initial call to CheckSafe. The rationale is that, when proving 
unrelated properties, it is likely that few calls are shared and 
that the book-keeping does not pay off. 

c) Handling successful proof attempts: When a re¬ 
cursive call yields a successful result, we can strengthen 
the program with the proven invariant. Remember that 
CheckSafe^, C, £c, (t, p)) = Safe means that whenever 
the transition t is used in any evaluation, p holds in the 
succeeding state. Thus, we can add this knowledge explicitly 
and change the transition in the original program. In practice, 
this strengthening is applied only if the first call to CheckSafe 
was successful, i.e, no narrowing was applied. The reason 
is that, if the transition relation of t was obtained through 
repeated narrowing, in general one needs to split transitions, 
and it is not correct to just add p' to t. Namely, assume 
that t 0 = (£,t 0 ,£') is the original (unnarrowed) version of 
a transition t = (£,t,£') £ Sc- As t is an entry transition 
of C, we have r = r Q A A ... A by construction, 
where tpi is the additional constraint we added in the i-th 
narrowing of component entries. Thus what we proved is that 

V.. .Vijj' m \/p' always holds after using transition t 0 . So we 
should replace t D in the program with a transition labeled with 
t 0 A (r/>j V ... V ij)' m V p'). As we cannot handle disjunctions 
natively, this implies replacing t 0 by m + 1 new transitions. 

Note that this program modification approach, unlike mem¬ 
oization, makes the gained information available to the Max- 
SMT solver when searching for a conditional invariant. A 
similar strategy can be used to strengthen the transitions in 
the considered component C. 

d) Parallelizing & distributing the analysis: Our analysis 
can easily be parallelized. We have implemented this at two 
stages. First, at the level of the procedure CondSafe, we try at 
the same time different numbers of template conjuncts (lines 
3-6 in Algo. [TJ, which requires calling several instances of 


the solver simultaneously. Secondly, at a higher level, the 
recursive calls of CheckSafe (line 9 in Algo.0 are parallelized. 
Note that, since narrowing and the “learning” optimizations 
described above are considered only locally, they can be 
handled as asynchronous updates to the program kept in each 
worker, and do not require synchronization operations. Hence, 
distributing the analysis onto several worker processes, in the 
style of Bolt [0], would be possible as well. 

Other directions for parallelization, which have not been im¬ 
plemented yet, are to return different conditional invariants in 
parallel when the Max-SMT problem in procedure CondSafe 
has several solutions. Moreover, based on experimental obser¬ 
vations that successful safety proofs have a short successful 
path in the tree of proof attempts, we are also interested in 
exploring a look-ahead strategy: after calling CondSafe in 
CheckSafe, we could make recursive calls of CheckSafe on 
some processes while others are already applying narrowing. 

e) Iterative proving: Finally, one could store the condi¬ 
tional invariants generated during a successful proof, which 
are hence invariants, so that they can be re-used in later runs. 
E.g., if a single component is modified, one can reprocess it 
and compute a new precondition that ensures its postcondition. 
If this precondition is implied by the previously computed 
invariant, the program is safe and nothing else needs to 
be done. Otherwise, one can proceed with the preceding 
components, and produce respective new preconditions in a 
recursive way. Only when proving safety with the previously 
computed invariants in this way fails, the whole program 
needs to be reprocessed again. This technique has not been 
implemented yet, as our prototype is still in a preliminary 
state. 

V. Related Work 

Safety proving is an active area of research. In the recent 
past, techniques based on variations of counterexample guided 
abstraction refinement have dominated m-m. These meth¬ 
ods prove safety by repeatedly unfolding the program relation 
using a symbolic representation of program states, starting in 
the initial states. This process generates an over-approximation 
of the set of reachable states, where the coarseness of 
the approximation is a consequence of the used symbolic 
representation. Whenever a state in the over-approximation 
violates the safety condition, either a true counterexample 
was found and is reported, or the approximation is refined 
(using techniques such as predicate abstraction lf24l or Craig 
interpolation ll25l ). When further unwinding does not change 
the symbolic representation, all reachable states have been 
found and the procedure terminates. This can be understood as 
a “top-down” (“forward”) approach (starting from the initial 
states), whereas our method is “bottom-up” (“backwards”), i.e. 
starting from the assertions. 

Techniques based on Abstract Interpretation [26] have had 
substantial success in the industrial setting. There, an abstract 
interpreter is instantiated by an abstract domain whose ele¬ 
ments are used to over-approximate sets of program states. The 
interpreter then evaluates the program on the chosen abstract 


domain, discovering reachable states. A widening operator, 
combining two given over-approximations to a more general 
one representing both, is employed to guarantee termination 
of the analysis when handling loops. 

“Bottom-up” safety proving with preconditions found by 
abduction has been investigated in {27]. This work is closest 
to ours in its overall approach, but uses fundamentally dif¬ 
ferent techniques to find preconditions. Instead of applying 
Max-SMT, the approach uses an abduction engine based 
on maximal universal subsets and quantifier elimination in 
Presburger arithmetic. Moreover, it does not have an equivalent 
to our narrowing to exploit failed proof attempts. In a similar 
vein, (28]| uses straight-line weakest precondition computation 
and backwards-reasoning to infer loop invariants supporting 
validity of an assertion. To enforce a generalization towards 
inductive invariants, a heuristic syntax-based method is used. 

Automatically constructing program proofs from indepen¬ 
dently obtained subproofs has been an active area of research 
in the recent past. Splitting proofs along syntactic boundaries 
(e.g., handling procedures separately) has been explored in (T|, 
ED, ED, HD- For each such unit, a summary of its behavior 
is computed, i.e., an expression that connects certain (classes 
of) inputs to outputs. Depending on the employed analyzers, 
these summaries encode under- and over-approximations of 
reachable states ID or changes to the heap using separation 
logic’s frame rule 0. Finally, H discusses how such compo¬ 
sitional analyses can leverage cloud computing environments 
to parallelize and scale up program proofs. 

VI. Implementation and Evaluation 

We have implemented the algorithms from Sect. IIV-AI and 
Sect. IIV-BI in our early prototype VeryMax, using the Max- 
SMT solver for non-linear arithmetic lf30l in the Barcel- 
ogic OTI system. We evaluated a sequential (VeryMax-Seq) 
and a parallel (VeryMax-Par) variant on two benchmark sets. 

The hist set (which we will call HOLA-BENCHS) are the 
46 programs from the evaluation of safety provers in E) 
(which were collected from a variety of sources, among others, 
H3], ll32| - l42l . the NECLA Static Analysis Benchmarks, etc.). 
The programs are relatively small (they have between 17 and 
71 lines of code, and between 1 and 4 nested or consecutive 
loops), but expose a number of “hard” problems for analyzers. 
All of them are safe. 

On this first benchmark set we compare with three systems. 
The first two were leading tools in the Software Verifica¬ 
tion Competition 2015 l43l : CPAchecket0 {44], which was 
the overall winner and in particular won the gold medal 
in the “Control Flow and Integer Variables” category, and 
SeaHorn l45l . which got the silver medal, and also won 
the “Simple” category. We also compare with HOLA l27l . 
an abduction-based backwards reasoning tool. Unfortunately, 
we were not able to obtain an executable for HOLA. For 
this reason we have taken the experimental data for this tool 

9 We ran CPAchecker with two different configurations, predicateAnaly- 
SiS and SV-C0mp15. 


directly from l27l . where it is reported that the experiments 
were performed on an Intel i5 2.6 GHz CPU with 8 Gb of 
memory. For the sake of a fair comparison, we have run the 
other tools on a 4-core machine with the same specification, 
using the same timeout of 200 seconds. Tab. Q] summarizes 
the results, reporting the number of successful proofs, failed 
proofs, and timeouts (TO), together with the respective total 
runtimes. Both versions of VeryMax are competitive, and our 
parallel version was two times faster than our sequential one 
on four cores. As a reference, on these examples VeryMax- 
Seq needed 2.8 overall calls (recursive or after narrowings) on 
average, with a maximum of 16. The number of narrowings 
was approximately 1, with a maximum of 13. Our memoiza- 
tion technique making use of already failed proof attempts was 
employed in about one third of the cases. 

In our second benchmark set (which we will refer to as 
NR-BENCHS) we have used integer abstractions of 217 
numerical algorithms from lf46l . For each procedure and for 
each array access in it, we have created two safety problems 
with one assertion each, expressing that the index is within 
bounds. In some few cases the soundness of array accesses in 
the original program depends on properties of floating-point 
variables, which are abstracted away. So in the corresponding 
abstraction some assertions may not hold. Altogether, the 
resulting benchmark suite consists of 6452 problems, of up 
to 284 lines of C code. Due to the size of this set, and to give 
more room to exploit parallelism (both tools with which we 
compare on these benchmarks, CPAchecker and SeaHorn, 
make use of several cores), we performed the experiments with 
a more powerful machine, namely, an 8-core Intel i7 3.4 GHz 
CPU with 16 GB of memory. The time limit is 300 seconds. 

The results can be seen in Tab. El On these instances, 
VeryMax is able to prove more assertions than any of the 
other tools, while being about as fast as SeaHorn, and 
significantly faster than CPAchecker. Note that many exam¬ 
ples are solved very quickly in the sequential solver already, 
and thus do not profit from our parallelization. VeryMax 
is at an early stage of development, and is hence not yet 
fully tuned. For example, a number of program slicing tech¬ 
niques have not been implemented yet, which would be 
very useful for handling larger programs. Thus, we expect 
that further development will improve the tool performance 
significantly. The benchmarks and our tool can be found at 
http://www.cs.upc.edu/~albert/VeryMax.html 

VII. Conclusion 

We have presented a novel approach to compositional safety 
verification. Our main contribution is a proof framework that 
refines intermediate results produced by a Max-SMT-based 
precondition synthesis procedure. In contrast to most earlier 
work, we proceed bottom-up to compute summaries of code 
that are guaranteed to be relevant for the proof. 

We plan to further extend VeryMax to cover more pro¬ 
gram features and include standard optimizations (e.g., slicing 
and constraint propagation with simple abstract domains). It 
currently handles procedure calls by inlining, and does not 






Tool 

Safe 

£ s 

Fail 

£ s 

TO 

Total s 

CPAchecker sv-comp15 

33 

2424.41 

3 

61.28 

10 

4489.73 

CPAchecker predicateAnalysis 

25 

503.05 

11 

19.72 

10 

2271.12 

SeaHorn 

32 

7.95 

13 

3.477 

1 

211.56 

HOLA 

43 

23.53 

0 

0 

3 

623.53 

VeryMax-Seq 

44 

293.14 

2 

50.69 

0 

343.83 

VeryMax-Par 

45 

138.40 

1 

12.81 

0 

151.21 


TABLE I 

Experimental results on HOLA-BENCHS benchmark set. 


Tool 

Safe 

£ s 

Unsafe 

£ s 

Fail 

£ s 

TO 

Total s 

CPAchecker sv-comp15 

5570 

614803.98 

251 

6188.30 

326 

28749.78 

305 

735336.82 

CPAchecker predicateAnalysis 

5928 

23417.15 

170 

495.13 

234 

9105.69 

120 

64652.29 

SeaHorn 

6077 

4276.21 

233 

135.25 

80 

529.09 

62 

24167.11 

VeryMax-Seq 

6105 

5940.88 

0 

0 

326 

26739.30 

21 

38980.80 

VeryMax-Par 

6106 

4789.73 

0 

0 

346 

18878.42 

0 

23668.15 


TABLE II 

Experimental results onNR-BENCHS benchmark set. 


support recursive functions yet. However, they can be handled 
by introducing templates for function pre/postconditions. 

In the future, we are interested in experimenting with alter¬ 
native precondition synthesis methods (e.g., abduction-based 
ones). We also want to combine our method with a Max-SMT- 
based termination proving method E) and extend it to exis¬ 
tential properties such as reachability and non-termination [5|. 
We expect to combine all of these techniques in an alternating 
procedure ID that tries to prove properties at the same time as 
their duals, and which uses partial proofs to narrow the state 
space that remains to be considered. Eventually, these methods 
could be combined to verify arbitrary temporal properties. 
In another direction, we want to consider more expressive 
theories to model program features such as arrays or the heap. 
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Appendix A 
Proofs 

Proof of Thin. [7] That Q is a conditional inductive invariant 
follows directly from the structure of the generated constraints, 
which are (modulo renaming) also discussed in QjQ. 

We prove the claim about conditional safety by contradic¬ 
tion via induction over the length of evaluations. Assume that 
there is an unsafe execution 

{ill ft) "Ati {ill vf) —>t 2 ■ ■ ■ — {ini v n) 

of length n £ N>i such that t\ £ £e U C (i.e., £2 is always 
a location in C), t n = t ex it, V2 \= Q{if) and v n f P- We 
will show that no such evaluation can exist, implying our 
proposition as the special case t\ £ £c- 

As the component graph is a DAG, t-\ £ £c U C and £ cxil is 
an exit transition of C, we have t j £ C for all 1 < i < n. 

We first consider the case n 2 (n = 1 would be the 

case where t\ is both an entry and exit transition, and thus 
infeasible). Let t 2 = {£i,T 2 , t 2 ). Then, v 2 |= Q{£ 2 ) = a{Ii 2 ,k) 
by choice and definition, and a{Ie 2 t k) At 2 =>■ ip' by constraint 
Sfc. Thus, no unsafe evaluation of length 2 is possible. 

We now assume n > 2 and that the proposition has been 
proven for evaluations of length n — 1. Let t 2 = {£ 2 iT 2l £ 3 ). 
For length n, we have that the valuations v 2 , v :i satisfy t 2 , 
and v 2 |= Q{£ 2 ) = < J {h 2 ,k)- These are the premises of our 
consecution constraint C.t 2 ,k = h 2t k A t 2 =>• h 3 ,k, and thus 
i>3 |= o{Ii 3 t k) = Q{£ 3)- Hence, we instead have to consider 
the evaluation of length n — 1 starting in (£ 2 ,v 2 ), which by 
our hypothesis is infeasible. □ 

Proof of Thin. 0 We prove the proposition by induction over 
the number u of recursive calls of CheckSafe. 

In the base case u = 0, we have that r ex i t => ip' , i.e., 
the condition to prove is always a consequence of using the 
transition f e xit, and the claim trivially holds. 

Let now u > 0, and we assume that the proposition has 
been shown for all calls of CheckSafe that return Safe and 
need at most u — 1 recursive calls of CheckSafe. 

We now consider a program evaluation 

(4, ^o) >t 0 ■ • ■ {£mi Dm) ■ ■ • £ t n {£ni Hn) 

with t m -i £ £c and t n = fexit- 

First, we consider the case that CheckSafe returns Safe 
in line 11, where all preconditions are satisfied for all entry 
transitions. By the condition ML £ Q{£ m ). res[t m _i,L] = 
Safe and our induction hypothesis, we know that the program 


is safe for (f m _ 1 , Q{£ m )). By construction of Q and Thm. Q] 
this then implies that the program is safe for (f ex it, p)- 

The second case is returning the result of CheckSafe on the 
narrowed program in lines 19 and 20. For this, we need to 
prove that our program narrowing is indeed correct. Assume 
now that the considered evaluation is unsafe, i.e., that v n \f= ip. 
We will show that our narrowing preserves unsafe evaluations. 
Then, as the recursive call of CheckSafe (with recursion depth 
u — 1 ) is correct by our induction hypothesis, we can conclude 
that Safe is only returned if there are no unsafe evaluations. 

We first consider the narrowing £):■ By our induction hy¬ 
pothesis, we know that v m 4 (AL eC (^),res[t m _ 1 ,L]=Safe L ') 
holds. Now assume that the narrowed version of f m _ 1 is 
not enabled anymore because of the added condition. Then 

Vm If -(AL e Q(« m ),res[t m _ 1 ,L]=Maybe i ') holds ’ and thus 
v m 4 I\l£Q(£ ) 4- But then, our evaluation is safe (by 
the same argument as in the proof of Thm. [TJ. contradicting 
our assumption that the considered evaluation is unsafe. Thus, 
unsafe evaluations are not broken by our narrowing of entry 
transitions. 

Similarly, we now consider the narrowing C. We consider 
an evaluation step {£ w ,v w ) —>t w {£w+h v w +{) with t w £ C. 
If the narrowed version t w £ C of t w cannot be used, 
then either v w \= Q{£ w ) or v w+ i \= Q(£ w +i) holds, and 
again, by an argument similar to the proof of Thm. Q] this 
contradicts the assumption that our evaluation is unsafe. Thus, 
unsafe evaluations are preserved by narrowing of the program 
component. □ 

Appendix B 

Choice of Weights in the Max-SMT Formulation 

In VeryMax, all weights for the initiation conditions are 
currently the same. Choosing different weights would bias the 
solver towards satisfying certain initiation conditions. Weights 
play a crucial role in VeryMax to favor invariants that imply 
postconditions over ones that disable transitions (cf. Sect. IV- 
C-a). The chosen MaxSMT framework also allows adding 
other techniques with lower weights, e.g. the techniques from 
0 that strengthen single program transitions during the anal¬ 
ysis. 


